Day12 到 Day15，我們分別從四個角度檢查了 RAG 的檢索結果。今天不介紹新指標，而是把這四個指標放在一起，看它們如何互補、怎麼組合判讀，以及分數不好的時候該往哪裡找問題。

前三個指標檢查的是 Retriever 交出來的 Context 本身，Context Precision（上下文精確度）看找回來的準不準，Context Recall（上下文召回率）看該找的有沒有漏，Context Entities Recall（實體召回率）看關鍵事實齊不齊；而 Noise Sensitivity（雜訊敏感度）檢查的是模型拿到不完美的 Context 之後，表現穩不穩定。

用同一個例子串起四個指標

還是那個問題：「特休一天需要提前幾天申請？」

• Precision 檢查的是，找回來的五個片段裡，是不是混進了加班規定和員工旅遊辦法。
• Recall 檢查的是，「提前天數」「核准流程」「例外處理」這三項必要資訊，有沒有漏掉哪一項。
• Entities Recall 檢查的是，找回來的內容雖然寫著「應提前申請」，但最關鍵的「3 天」有沒有真的出現。
• Noise Sensitivity 檢查的是，即使 Context 裡混進雜訊，模型還能不能答出「3 天」，而不是把別的規定誤植進答案。

四個指標問的是同一次檢索的四個不同層次：準不準、全不全、關鍵事實齊不齊、雜訊來了穩不穩。

組合起來看，才能定位問題

單看一個分數，只能知道好或不好；組合起來看，才能知道問題出在哪。

• Precision 高、Recall 低：找得準但不完整，結果很精簡，卻漏掉了必要資訊。
• Precision 低、Recall 高：該找的都找到了，但混進大量無關內容，這時候 Reranker 和 Top-K 的設定值得優先檢查。
• Recall 尚可、Entities Recall 低：內容看起來相關，但決定答案的數字或名稱不見了，要回頭檢查 Chunking 有沒有把關鍵資訊切散。
• 前三項都不錯、Noise Sensitivity 偏高：檢索本身沒有大問題，但系統遇到不完美的 Context 就容易失準，需要提升對雜訊的穩定度。

這也是評測真正的價值。看到答案錯誤，不該只說「模型答錯了」，而是要透過這些分數回頭問：是資料沒找到、關鍵事實缺了，還是找到了卻被雜訊干擾？分數的作用不只是打分，而是幫我們縮小排查的範圍。

檢索好，不代表答案就對

不過，就算四個指標都表現良好，也只能說明我們交給語言模型的 Context 品質不錯，不能保證它一定會答對。Context 交出去之後，模型有沒有正確理解、有沒有忠實使用這些內容、答案本身是否正確，是另一組不同的問題。

所以從下一篇開始，我們要從「有沒有找到對的資料」，走向「找到之後有沒有用對」，依序介紹回答品質的四個指標：Answer Relevancy（答案相關性）、Faithfulness（忠實度）、Factual Correctness（事實正確性）與 Topic Adherence（主題連貫性）。